因為自己有一本基于SQL Server 2005的數(shù)據(jù)庫教程,里邊使用的
示例數(shù)據(jù)庫是AdventureWorks for SQL Server 2005,而我的機子上裝的是SQL Server 2008,示例數(shù)據(jù)庫是AdventureWorks for SQL Server 2008。起初我以為示例數(shù)據(jù)庫AdventureWorks for SQL Server 200
5 與AdventureWorks for SQL Server 200
8 數(shù)據(jù)庫結(jié)構(gòu)應(yīng)該差不多,可是在練習(xí)的過程中,我發(fā)現(xiàn)兩個數(shù)據(jù)庫中很多表的結(jié)構(gòu)還是有很多不一樣的地方。于是決定到微軟下載中心將示例數(shù)據(jù)庫AdventureWorks for SQL Server 2005下過來,附加到SQL Server 2008上,以便順利進行練習(xí)。我以SQL Server 2008的超級管理員賬戶“
sa”連接登錄到實例SQLSERVER2008:
在附加示例數(shù)據(jù)庫AdventureWorks for SQL Server 2005時,彈出了下圖這個錯誤:
仔細看了一下主要信息“嘗試打開或創(chuàng)建物理文件......時,CREATE FILE遇到操作系統(tǒng)錯誤 5(拒絕訪問。)” ,一看就知道應(yīng)當(dāng)是對要附加的數(shù)據(jù)文件的操作權(quán)限不夠。 按一般的思維習(xí)慣,我們會對操作權(quán)限不夠的文件授予足夠的操作權(quán)限。比如,有網(wǎng)友說“給要附加的數(shù)據(jù)文件和相應(yīng)的日志文件授予Everyone的權(quán)限”,授權(quán)過程如下三張截圖所示(注意數(shù)據(jù)文件和日志文件都必須授權(quán)):
(圖1:授權(quán)數(shù)據(jù)文件)
(圖2:數(shù)據(jù)文件授權(quán)后)
(圖3:日志文件授權(quán)后)
對要附加的數(shù)據(jù)文件和日志文件分別授予Everyone【讀取和執(zhí)行】、【讀取】的權(quán)限后,在SQL Server 2008中重新嘗試附加數(shù)據(jù)庫,發(fā)現(xiàn)可以附加成功了! 是不是問題就這樣解決了呢?這樣子做對嗎? 如果在真實的數(shù)據(jù)庫管理過程中,我們把數(shù)據(jù)文件、日志文件的權(quán)限放大到Everyone,那肯定是不對的做法。因為這樣數(shù)據(jù)庫的安全性將大打折扣,雖然對Everyone只授予了【讀取和執(zhí)行】、【讀取】的權(quán)限,但這仍然有泄漏數(shù)據(jù)的危險。
我們應(yīng)當(dāng)保證能正常訪問的情況下,使數(shù)據(jù)文件具有最小的訪問權(quán)。我們之前授權(quán)給Everyone,那所有用戶或賬戶都能操作相應(yīng)的文件了,這肯定不安全的。那么如何才能授予最小的訪問權(quán)限呢?思考一下,我們用SQL Server 2008去附加相應(yīng)的數(shù)據(jù)文件,報出“拒絕訪問”即權(quán)限不夠的錯誤,換句話說,當(dāng)前SQL Server 2008沒有權(quán)限訪問這些文件。我們右鍵文件,到文件屬性中查看一下文件的權(quán)限情況,如下圖所示:
(相應(yīng)數(shù)據(jù)文件原本的權(quán)限情況)
我們發(fā)現(xiàn)只有SYSTEM和xrm這兩個組或用戶才有權(quán)操作此數(shù)據(jù)文件。SYSTEM是一個用戶組,即【本地系統(tǒng)】組,而xrm是一個管理員用戶,如圖示:
(xrm用戶的信息)
SYSTEM用戶組和xrm這個管理員用戶都有權(quán)限操作此數(shù)據(jù)文件和日志文件,而以SQL Server 2008的超級管理員SA連接登錄實例后,SQL Server卻沒有權(quán)限訪問此數(shù)據(jù)文件。換句話說,以SQL Server 2008的超級管理員SA連接登錄實例后,登錄的身份不在SYSTEM用戶組,也不是xrm這個管理員。那會是什么呢?
我們查看一下當(dāng)前SQL Server 2008的實例服務(wù)的相關(guān)信息就知道了,打開Sql Server Configuration Manager (即SQL Server 配置管理器)查看一下當(dāng)前連接到的實例服務(wù)的相關(guān)信息,如下圖所示:
(當(dāng)前實例服務(wù)的相關(guān)信息)
發(fā)現(xiàn)當(dāng)前實例SQLSERVER2008的登錄身份為“NT AUTHORITY\LocalService”,即操作系統(tǒng)授權(quán)的【本地服務(wù)】,本地服務(wù)也是了個用戶組。換句話說,如果我們僅授予【本地服務(wù)】這個用戶組的權(quán)限(而不是Everyone),應(yīng)該也可以在SQL Server 2008中用sa的賬戶附加數(shù)據(jù)庫了。為此,將剛剛授予相應(yīng)數(shù)據(jù)文件和日志文件Everyone的權(quán)限都刪除,再授予LocalService用戶組相應(yīng)數(shù)據(jù)文件和日志文件的權(quán)限,重新嘗試附加相應(yīng)的數(shù)據(jù)庫,發(fā)現(xiàn)的確可以附加成功!不必說,授予操作系統(tǒng)授權(quán)的【本地服務(wù)】用戶組比起授予Everyone來說肯定要安全的多。
上面提到的方法中,我們都是改變了數(shù)據(jù)文件原來的權(quán)限范圍(原來的權(quán)限范圍只有SYSTEM即【本地系統(tǒng)】用戶組和xrm這個系統(tǒng)管理員) 。而更好的辦法是不要改變數(shù)據(jù)文件的權(quán)限范圍,仍然以SA身份連接登錄SQL Server 2008的實例也能訪問相應(yīng)的數(shù)據(jù)文件。而要達到這個目的,我們只需要將相應(yīng)實例的登錄身份改為SYSTEM【本地系統(tǒng)】用戶組,SYSTEM也是在相應(yīng)數(shù)據(jù)文件的權(quán)限范圍之內(nèi)的用戶組,而且SQL Server實例以本地系統(tǒng)身份運行,安全性將更高。我們可以在SQL Server 配置管理器中將相應(yīng)的SQL Server實例的登錄身份修改為【本地系統(tǒng)】即Local System,如下列圖所示:
(修改實例的登錄身份)
(實例的登錄身份變?yōu)長ocalSystem)
然后重啟相應(yīng)實例服務(wù),重新以SA身份連接登錄SQL Server 2008的相應(yīng)實例并嘗試附加數(shù)據(jù)庫, 同樣可以成功的將數(shù)據(jù)庫附加上!!
其實,如果不是要特別地以SA身份連接登錄SQL Server 2008的相應(yīng)實例來附加相應(yīng)數(shù)據(jù)庫,那么在連接登錄SQL Server 2008的相應(yīng)實例時,身份驗證選擇【W(wǎng)indows 身份驗證】,不做前文中所述的其他修改就可以把數(shù)據(jù)庫附加上去了,原因就在于:【W(wǎng)indows 身份驗證】用的是當(dāng)前操作系統(tǒng)的用戶的權(quán)限,權(quán)限一般都足夠大的。另外,在【SQL Server 配置管理器】中針對實例服可以做的操作,在Windows的【服務(wù)】上也可以做到。